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By considering an essential subset of the BPEL orchestration language, we define SeB, a session based 
style of this subset. We discuss the formal semantics of SeB and we present its main properties. We 
use a new approach to address the formal semantics, based on a translation into so-called control 
graphs. Our semantics handles control links and addresses the static semantics that prescribes the 
valid usage of variables. We also provide the semantics of collections of networked services. 

Relying on these semantics, we define precisely what is meant by interaction safety, paving the 
way to the formal analysis of safe interactions between BPEL services. 

1 Introduction 

In service-oriented computing, services are exposed over a network via well defined interfaces and spe- 
cific communication protocols. The design of software as an orchestration of services is an active topic 
today. A service orchestration is a local view of a structured set of interactions with remote services. 

In this context, our endeavour is to guarantee that services interact safely. The elementary construct in 
a Web service orchestration is a message exchange between two partner services. The message specifies 
the name of the operation to be invoked and bears arguments as its payload. An interaction can be long- 
lasting because multiple messages of different types can be exchanged in both directions before a service 
is delivered. 

The set of interactions supported by a service defines its behavior. We argue that the high levels 
of concurrency and complex behavior found in orchestrations make them susceptible to programming 
errors. Widely adopted standards such as the Web Service Description Language (wsdl) Q provide sup- 
port for syntactical compatibility analysis by defining message types in a standard way. However, wsdl 
defines one-way or request-response exchange patterns and does not support the definition of more com- 
plex behavior. Relevant behavioral information is exchanged between participants in human-readable 
forms, if at all. Automated verification of behavioral compatibility is impossible in such cases. 

The present paper is a first step towards addressing the problem of behavioral compatibility of Web 
services. To that end, we follow the promising session based approach. Indeed, the session paradigm 
is now an active area of research with potential to improve the quality and correctness of software. We 
chose to adapt and sessionize a significant subset of the industry standard orchestration language bpel 
Ifl8l . We call the resulting language SeB (Sessionized bpel). It supports the same basic constructs as 
bpel, but being a proof of concept, it does not include the non basic bpel constructs such as exception 
handling. These differences are explained in more detail in section 2. 

On the other hand, SeB extends bpel by featuring sessions as first class citizens. A client wishing to 
interact with a service begins by opening a session with this service. The set of possible interactions with 
the service forms the behaviour of the session. In the present paper, we concentrate on the definition of 
untyped SeB. In the future we plan to define session types in order to allow us to verify interaction safety 
by means of type verification. 
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In order to define the SeB language, we give a formal semantics that is a novel contribution in itself 
as it takes into account both the graph nature of the language and the static semantics that define how 
variables are declared and used, and this is applicable to other bpel like languages. Indeed, previous 
approaches either resort to process algebraic simplifications, thus neglecting control links which, in fact, 
are an essential part of bpel; or are based on Petri nets and thus do not properly cover the static semantics 
that regulate the use of variables. 

In our approach, the operational semantics is obtained in two steps. The first consists in the creation 
of what we have called a control graph. This graph takes into account the effect of the evaluation of 
the control flow and of join-conditions. Control graphs contain symbolic actions and no variables are 
evaluated in the translation into control graphs. The second step in the operational semantics describes 
the execution of services when they are part of an assembly made of a client and other Web services. 
Based on this semantics we formalize the concepts of interaction error and of interaction safety. These 
concepts will be further developed in future work on verification of session typing. 

The rest of this paper is organized as follows. Section 2 provides an informal introduction to the SeB 
language and contrasts its features with those of bpel. Sections 3 and 4 give the syntax and semantics 
of untyped SeB. These sections are self-contained and do not require any previous knowledge of bpel. 
Section 5 presents the semantics of networked service configurations described in SeB, and the concepts 
of interaction error and of interaction safety. Relevant related work is surveyed in section 6 and the paper 
is concluded in section 7 along with a brief discussion on how session types might be used in SeB in 
order to prove interaction safety. 

2 Informal introduction to SeB 

Session initiation. The main novelty in SeB, compared to bpel, resides in the addition of the session initi- 
ation, a new kind of atomic activity, and in the way sessions impact the invoke and receive activities. The 
following is a typical sequence of three atomic SeB activities that can be performed by a client (we use a 
simplified syntax): s@p; s\op\(x)\ s1op2(y)- This sequence starts by a session initiation activity, s@p, 
where s is a session variable and p a service location variable (this corresponds to a bpel partnerlink). The 
execution of s@p by the client and by the target service (the one whose address is stored in p) has the fol- 
lowing effects: (i) a fresh session id is stored in s, (ii) a new service instance is created on the service side 
and is dedicated to interact with the client, (iii) another fresh session id is created on the service instance 
side and is bound to the one stored in s on the client side. The second activity, s\op\ (x), is the sending 
of an invocation operation, op\, with argument x. The invocation is sent precisely to this newly created 
service instance. The third activity of the sequence, s1op2(y), is the reception of an invocation operation 
op2 with argument y that comes from this same service instance. Note that invocation messages are all 
one way and asynchronous: SeB does not provide for synchronous invocation. Furthermore SeB does not 
provide for explicit correlation sets as does bpel. But, on the other hand, sessions are to be considered as 
implicit correlation sets and, indeed, they can be emulated by them. But, in this paper, we preferred to 
have sessions as an explicit primitive of the language so as to better discuss and illustrate their contribu- 
tion. Hence, in SeB, session ids are the only means to identify source and target service instances. This is 
illustrated in the above example where the session variable s is systematically indicated in the invoke and 
receive activities. Moreover, sessions involve two and only two partners and any message sent by one 
partner over a session is targeted at the other partner. Biparty sessions are less expressive than correlation 
sets. Nevertheless, at the end of the paper, we will give some ideas as to how this limitation can be lifted. 

Structured activities. SeB has the principal structured activities of bpel, i.e., flow, for running activ- 
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ities in parallel; sequence, for sequential composition of activities, and pick, which waits for multiple 
messages, the continuation behavior being dependent on the received message. SeB also inherits the 
possibility of having control links between different subactivities contained in a flow, as well as adding 
a join condition to any activity. As in bpel, a join condition requires that all its arguments have a defined 
value (true or false) and must evaluate to true in order for the activity to be executable. SeB also imple- 
ments so-called dead path elimination whereby all links outgoing from a canceled activity, or from its 
subactivities, have their values set to false. 

Imperative Computations. Given that SeB is a language designed as a proof of concept, we wished 
to limit its main features to interaction behavior. Hence, imperative computation and branching are not 
part of the language. Instead, they are assumed to be performed by external services that can be called 
upon as part of the orchestration. This approach is similar to languages like Ore ifTOl where the focus 
is on providing the minimal constructs that allow one to perform service orchestration functions and 
where imperative computation and boolean tests are provided by external sites. In particular, the original 
do until iteration of bpel is replaced in SeB by a structured activity called "repeat", given by the syntax: 
(do picj until pic 2 ). The informal meaning of repeat is: perform pic 1 repeatedly until the arrival of an 
invocation message awaited for in pic 2 . 

Example Service. The QuoteComparer is an example of a service written in SeB that will be used 
throughout the paper. Given an item description from a client, the purpose of the service is to offer a 
comparison of quotes from different providers for the item while at the same time reserving the item 
with the best offer. Figure [T] contains a graphical representation of the QuoteComparer implementa- 
tion. The representation is partial due to space constraints. The service waits for a client to invoke its 
so?searchQuote(desc) operation with string parameter desc containing an item description. Note the use 
of the special session variable sq, called the root session variable. By accepting the initial request from 
the client, the service implicitly begins an interaction with the client over session sq. The service then 
compares quotes for the item from two different providers (EZshop and QuickBuy) by opening sessions 
with each of these providers. Here, the sessions are explicitly opened: s@EZshop is the opening of a 
session with the service having its address stored in variable EZshop. The execution of s@EZshop will 
result in a root session being initiated at the EZshop service and a fresh session id being stored in s. 

The service then behaves in the following way: depending on the returns made by the two providers, 
the QuoteComparer service either returns the best quote, the only available quote, or indicates to the client 
that no quote is available. The control links and join conditions illustrated in Figure [T] implement this 
behaviour. For example, control link l\ is set to true if EZshop returns message quote (quotel), meaning 
EZshop has an offer for the item. The value of this link and others will be later used to determine which 
provider's quote should be chosen. Indeed, the join condition (given by JCD = (l\ and h) or I3) of the 
bottom left box that deals with reserving an item with EZshop depends on the value of control link l\ . 
It also depends on control link /3 which comes from the bottom central box that decides, in the case 
where both providers offer a quote, which quote is most advantageous. Link I2 will be set to true only 
if provider QuickBuy does not return a quote. Hence, the join condition of the bottom left box indicates 
that it should begin executing either if EZShop's quote is favourable (the control link I3 is set to true), or 
if EZShop returns a quote and QuickBuy returns noQuote (/1 and 1% are set to true). The conditions for 
reserving with the QuickBuy provider are symmetrical. 

If neither QuickBuy nor EZShop return a quote for the requested item, then control links and h are 
set to true. This results in the execution of the central invocation operation srf.not Found, i.e the client is 
informed that no quotes were found for the item description desc. 
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Figure 1: The QuoteComparer Service 



3 Syntax of SeB 
3.1 Basic Sets 

SeB assumes three categories of basic sets: values, variables and others. They are introduced hereafter 
where, for each set, a short description is provided as are the names of typical elements. All the sets are 
pairwise disjoint unless stated otherwise. 



Set 


Description 


Ranged over by 


DatVal 


Data Values 


U +U ■ l( j ■ *** 


SrvVal 


Service Locations 


71,71', 71,- ••• 


SesVal 


Session Ids 


a,a',ai ••• j6 ••• 


ExVal 


Exchangeable Values 


W,w' ,Wj, ■ ■ ■ 


LocVal 


All Locations 


8, 8', Si, ••• 


Val 


All Values 





Table 1: Values 



Table [T] presents the various sets of values used in SeB. Data Values (DatVal), Service Locations 
(SrvVal) and Sessions Ids (SesVal) are ground sets. The set of Exchangeable Values ExVal is given 
by ExVal = DatVal l±) SrvVal, which means that both data values and service locations can be passed 
between services. Hence, SeB services may dynamically discover other services and may interact with 
them. The set of all locations LocVal is given by LocVal = SrvVal fcd SesVal. Hence, session ids are used 
to locate service instances. The set of all values Val is given by Val = ExVal ttJ SesVal. 

Table [2] presents the various sets of variables. We can note two distinguished variables, po and sq: 
Pq, is the service location variable that is dedicated to holding a service's own location; so is a session 
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Set 


Description 


Ranged over by 


DatVar 


Data Variables 


y 


SrvVar 


Service Location Variables 


P0,P,p',Pi ■■■ q ■■■ 


ExVar 


Variables of Exchangeable Values 


X) X ; X( 


SesVar 


Session Variables 


so,s,s',Si ■■■ r ■■■ 


Var 


All Variables 





Table 2: Variables 



variable for accepting sessions initiated by clients. The use of po and so will be described in detail later 
on in the paper. The set of variables of exchangeable values ExVar and the set of all variables Var are 
defined by: ExVar = DatVar l±) SrvVar and Var = ExVar i±) SesVar. 



Set 


Description 


Ranged over by 


Op 


Operation Names 


op,op',opi ■■■ 


Lnk 


Control Links 


1,1 ,li 


^Lnk 


subsets of Lnk 


L,I*,l T ■■■ 


Jed 


Join Conditions 


e,e',ei •••/••• 



Table 3: Miscellaneous Sets 



Table [3] presents the other basic sets. Lnk is the set of all control links and Jed is the set of join con- 
ditions, i.e., boolean expressions over control links. An example of a join condition: e = (l\ and h) or 1$. 

Reconsidering our previous example, EZShop and QuickBuy are service location variables (elements 
of set SrvVar, with values taken in the set of service locations SrvVal ); desc is a data variable (with 
values in the set DatVal); so, s and q are session variables (elements of SesVar, taking their values in the 
set of session ids SesVal ); h, h and 1^ are control links; and finally, expression (£3 and h) or h is a join 
condition. 

3.2 Syntax of SeB Activities 

SeB being a dialect of bpel, XML would have been the most appropriate metalanguage for encoding its 
syntax. However, for the purpose of this paper, we have adopted a syntax based on records (a la Cardelli 
and Mitchell H) as it is better suited for discussing the formal semantics and properties of the language. 
By virtue of this syntax, all SeB activities, except nil, are records having the following predefined fields: 
knd which identifies the kind of the activity, beh, which gives its behavior, src (respectively tgt), which 
contains a declaration of the set of control links for which the activity is the source (respectively target), 
jcd which contains the activity's join condition, i.e., a boolean expression over control link names (those 
given in field tgt). Moreover, the, flow activity has an extra field, lnk, which contains the set of links that 
can be used by the subactivities contained in this activity. Field names are also used to extract the content 
of a field from an activity, e.g., if act is an activity, then act. beh yields its behavior. For example: a. flow 
activity is given by the record (knd = FLO , beh = my Jbehavior , tgt = L T , src = L s , jcd = e, lnk = L) where 
L T , L s and L are sets of control link names, and e is a boolean expression over control link names. Finally, 
for the sake of conciseness, we will often drop field names in records and instead we will associate a fixed 
position to each field. Hence, the flow activity given above becomes: (flo , my Jbehavior, L T ,L s ,e,L). 

We let ACT be the set of all activities and act a running element of ACT, the syntax of activities is 
given in the following table: 
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act ::= nil (* nil activity *) 

ses | inv | rec (* atomic activities *) 

seq | flo | pic | rep (* structured activities *) 



ses 


:= (ses ,s@ p, L 1 , L s , e) 


(* session init *) 


inv 


:= {mv ,slop(x u --- ,x n ), L T , L s , e) 


(* invocation *) 


rec 


:= {sec , slop (x\, ■ ■ ■ ,x n ), L T , L s , e) 


(* reception *) 


seq 


:= (seq , acti ; • • • ; act n , L T , L s , e) 


(* sequence *) 


flo 


:= (BLO,acti| ••• |act„, L T , L s , e,L) 


(* flow *) 


pic 


:= (HC,reci;actH h rec„;act„, L T , L s , e) 


(* pick *) 


rep 


:= (REP,<fo pic! until pic 2 , L T , L s , e) 


(* repeat *) 



Note that in the production rule for flo, "|" is to be considered merely as a token separator. It is 
preferred over comma because it is more visual and better conveys the intended intuitive meaning of the 
flo activity, which is to be the container of a set of sub activities that run in parallel. The same remark 
applies to symbols "+", "do" and "until" which are used as token separators in the production rules 
for seq, pic and rep to convey their appropriate intuitive meanings. Note that "|" and "+" are commuta- 
tive. As a final note, the number n appearing in the rules for seq, flo and pic is such that n > 1. 

Returning to Figure [T] the syntax of the central inv activity is given by the following expression: 
(inv, so\not Found , {le,h}, 0, h and 1$), and the syntax of the seq activity at the top left of the 
example is given by the following expression: 

(seq , 

(SES,s@EZshop, 0, 0, true) ; 
(fNV,slgetQuote(desc), 0, 0, true) ; 
(pic, 

(rec, slquote(quotel), 0, {l\,U}, true) + (rec, si no Quote, 0, {le,h}, true), 

0,0, true), 
0,0, true) 1 

Note: Syntax simplification - when an activity has no incoming or outgoing control links, we may omit 
its encapsulating record and represent it just by its behavior. Hence, for example, we may write act; act' 
instead of (seq, act; act', 0, 0, true), and we will write s\op(x) instead of (inv, slop(x), 0, 0, true). 

Definition 3.1. Subactivities - For an activity act, we define the sets of activities, act and act: 

• act = {act} if act is an atomic activity, else act = {act} U act.BEH 

• act = if act is an atomic activity, else act = act.BEH 

Informally, act is the set of activities transitively contained in act and act is the set of 
activities strictly and transitively contained in act. 

Definition 3.2. Precedence relation between activities - For an activity act, we define relation pred on 
the set act as follows: 

act\ pred acti_ iff ( act\ .src n acti.TQT ^ ) or ( 3seq G act with sec/.BEH = • • • act\ ; act% • • • ) 



Informally, relation pred implies that act\ preceeds act2 either in some seq activity or 
because act\ has at least one outgoing control link targeting act2- 
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Activities need to comply to certain constraints concerning the declaration and usage of their control 
links. Firstly, control links should be well scoped, unique and should form no cycles. Secondly, all rep 
subactivities should be well-formed in terms of incoming and outgoing control links. An activity that 
complies with these constraints is said to be well-formed. 

Definition 3.3. rep-well-formed activity - A SeB activity acta is rep-well-formed iff any activity 
rep= (rep, do pic { until pic 2 , L T , L s , e) of acto satisfies the following 3 conditions: 

(1 ) p/'q. tgt = p/'c 2 . tgt = 0, (2) p/q.SRC = 0, and (3) p/'q. src = p/q.TGT. 

Informally, (I) implies that p\c x and pic 2 have no incoming links, (2) states that pic^ has no 
outgoing links and (3) states that all control links of activities (strictly) contained in p/'q are 
(strictly) internal to p/'q. 

Definition 3.4. Well-structured activity - A SeB activity acto is well structured iff the control links 
occurring in any activity of acto satisfy the unicity, scoping and non cyclicity conditions given below, 
where act, act!, act!' and seq are subactivities of acto. 

1. Control links unicity - Given any control link I, and any pair of activities act and act': 

if (I G actLNK n act '.lnkJ or (I G act src n act '.src) or (I G act tgt n act '.tgt) then act = act'. 

2. Control links scoping - 7/7 £ act.sRc (respectively if I G act.TGT ) then 3 act', act" with act G act" 
and act' G act" and with I G act". lnk and I 6 act'. tgt. (respectively I £ act'. src). 

3. Control links non cyclicity: 

( i) Relation pred is acyclic, and 

(ii) V act, act' G acto act' £ act =>• ( act.sRc Pact 7 , tgt = ) and ( act!, src n act.TGT = ) 
Informally, a well-structured activity is such that all of its control links ( including those 

in subactivities) are well scoped (i.e., are within the scope of one flow subactivity), unique 
( each target declaration corresponds to one and only one source declaration and vice versa), 
and do not form any causality cycles, either directly (from source to target of activities) or 
through activities that are chained within some sequence activity or through the containment 
relation between activities. 
Definition 3.5. Well-formed activity - an activity is well formed iff it is both well structured and rep- 
well-formed. 

4 Semantics of SeB 

Here we define the notion of control graphs and then provide the sos rules that define a translation from a 
well-formed activity into a control graph. We then study the properties of control graphs. The semantics 
of SeB activities is obtained by applying a series of transformations to this first control graph that lead to 
a final control graph, noted cg(act). 

4.1 Definitions 
4.1.1 Control Graphs 

Definition 4.1. Observable Actions - The set, ACTIONS, of observable actions is defined by: 
ACTIONS =def{ a \ a is any action of the form: s@p, s\op(x\, ■ ■ ■ ,x n ) or slop(x\, ■ ■ ■ ,x n ) } 
Definition 4.2. All actions - We define the set ACTIONS^ of all actions ( ranged over by a): ACTIONS T = ief 
ACTIONS U {t} where T denotes the unobservable (or silent) action. 

Definition 4.3. Control Graphs - A control graph, T =< G,g ,g/,— » , is a labelled transition system 

— G is a set of states, called control states — g n is the initial control state 

where' 

- is a set of actions (srf C ACTIONS T ) > C G x srf x G 
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4.1.2 Control Link Maps 

We now define the control part of activities where we consider only the values of control links. Activities 
are given a map that stores the running values of control links, which are initially undefined values. 

Definition 4.4. - Control Link Maps - A Control link map c is a partial function from the set of control 
links, Lnk, to the set of boolean values extended with the undefined value, c : Lnk — > {true, false, _L} 

Definition 4.5. Initial Control Links Map - For an activity act we define c act , the initial control links 
map: dom(c 3C t) = {l £ Lnk \ I occurs in act} and \fl £ dom{c ac t) '■ c ac t(l) =-L 

Definition 4.6. Evaluation of a Join Condition - IfL is a set of control links, e a boolean expression over 
L and c a control links map, then the evaluation of e in the context of c is written: c\>e{L). Furthermore, 
we consider that this evaluation is defined only when Ml £ L,c(l) ^ _L. 

4.2 From Activities to Control Graphs: Structured Operational Semantics Rules 



ses | c>e(L T )= true | inv | c>e(L T ) = true 



{c,(sES,s@p,L T ,L s ,e)) {c,(lW,s\op(x),L T ,L s ,e)) 

4- s@p .J, s\op(x) 



rtrue 



(4 trU 7L s ],nil) 



rec c t> e(L T ) = true 
{c,(BEC,s1op(x),L T ,L s ,e)) 

4- slop(x) 

(4 trU 7zJ,nil) 



| dpe | c> e(L T ) = false 



>,(*, act, L T , L s , e)) 
|t 

actSRcl' nil ) 



(c[ false /; 



| pic | ct>e(L T ) = true (c, rec) (c' , nil) 
( c, (PIC , rec; act + £ rec, ; act,- , L T , L s , e ) ) 

( c'[ fa,s 7(Lrec^ctJ).SRC], (FLO, act , L T , L s , e ) 



repi | c>e(L T )= true (c, picj 



c'.act 



(c, (REP, do pici until pic2, L T , L s , e) ) 
(e',{UNF ,do act then pic; until pic2, L T ,L s ,e)) 



FLoi oe(L T )=true (c,act,-) — > (c',act') 
(c,{flo, acti|...[act,|..|act„ , L T , L s , e)) 

(c',(flo, acti|...|act'[...[act„ , L T , L s , e)) 



| REP2 c>e(L T ) = true (c, pic 2 ) — > (c',act) 

(c, (REP, do pic; until pic 2 , L T , L s , e) ) 
la 

(c', (FLO, act , L T , L s , e) ) 



| FLQ2 c > e(L T ) = true 

(c, (lLO,acti| .|nil| .|act„ , L T , L s , e) 

(c, (elo, acti|-|-|act„ , L T , L s , e) ) 



unfi | oe(L T ) = true (c,act) — > (c',acf) 



(c,(ww , do act then p\Ci until p\C2, L T , L s , e)) 
|ct 

(c', (UNF act' then p'\C \ until pic2, L T , L s , e)) 



flo3 | oc(4) = true 



(c,<flo, nilA.i^^^CcI^l.nil) 



oe(L T ) = true 



(c, (UNF.iio nil rten pic i until pic2, L T ,L S , e)) 

|t 

(c', (REP , do pici until pic2 ,L T ,L s ,e) ) 
where 

c ' = I V 1 — 1 i /=—= ' true /pic,.SRc] 
pic,. SRC piC,.TGT H 1 



Table 4: Structured Operational Semantics 



In Table 4 we provide the sos rules defining a translation from activities to control graphs. Some 
comments are in order concerning this table: 



the notation for value substitution in control link maps requires some explanation: c[ e //] 



def ' 
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where c'(l') = c(l) for l^V and c'(Z) = true. By abuse of notation, we also apply value substitution to 
sets of control links. Hence, if n is a set of activities, then, e.g., c[ false /IT.sRc] is the substitution whereby 
any control link occurring as source of an activity in IT has its value set to false. 

• the rules for the seq activity have been skipped as for any seq one can construct a behaviorally equiva- 
lent flo activity having the same set of subactivities. This is mereley achieved by introducing the appro- 
priate control links between any two consecutive subactivities. 

• in the rules for activity flo we have dropped the field lnk since its value is constant (lnk is used to 
define a scope for control link variables). 

• in the rules for the repeat activity rep, we have introduced a new activity, unf (unfold). Its syntax is: unf 
::= (unf, do act then picj until pic 2 , L T , L s , e). Activity unf is introduced as a result of the execution of 
rule repi. This mirrors the unfolding of an iteration by activity picx . Rule unfi represents the execution 
of an action by the unfolded activity and rule UNF2 represents the termination of the iteration whereby unf 
is transformed back into a rep activity identical to the original one. Note how, in this transformation, all 
links (strictly) contained in pic 1 are reset to the undefined value. The rep activity as a whole terminates 
by means of rule REP2 representing the activation of activity pic 2 . 

• as a notational convention, we have used "*" to denote a wildcard activity, as seen in the rule for 
dead-path elimination (dpe). 



in 



When applied to the initial control state (c act , act) of a well formed activity act, the sos rules defined 
Table 4 yield a first control graph, the raw control graph, that we note r-cg(act). A transition in this 

> (c" act"). 



control graph will be denoted by (c', act') 



4.3 Properties of Raw Control Graphs 
Property 1. The set of states of r-cg(act) is finite. 

Proof. We can structurally define function # 6 (act) that gives an upper bound for the number of states 
generated from an activity act. To obtain this upper bound we consider an empty set of control links 
so as to allow the maximum possible interleaving and hence generating the maximum number of states. 
This upper bound is structurally defined as follows: 

# „i,( nil ) =1 # J inv )= # „»( rec )= # J ses )= 2 # b ({im>,do picj until pic 2 , , ,))=#„(pic 1 ) +#„(pic 2 ) + 1 
#J(lM),acti|--- lack, , , )) = (# 6 (act 1 ) + l)x...x(# 6 (act, J ) + l) + l 
# 6 ((pic,reci;acti H h rec„;act„, , , )) = # Mi (acti) +2 + . . . +# 6 (act n ) +2 + 1 

□ 

Property 2. r-cg(act) is free of X loops. 

Proof. The only case in which a x loop could appear is in the picj of a repeat activity. But since pic 
necessarily contains an initial receive activity, any potential X loop is broken by this receive activity. □ 

Property 3. r-cg(act) is x-confluent, i.e.: 

g g\ and g g 2 => 3g' where g\ g' and g 2 — >■ g' 

act act act act 

Proof, (sketch) Let us consider the situation where from some state (c, acto) we can fire two transitions: 
(1) (c,actrj) —> (ci,acti) and (2) (c,acto) -^->- (c 2 ,act 2 ). Since one of the actions is X then there is 
necessarily a subactivity flo G acto with flo = (flo, • • • act[ | • • • |act 2 • • • , L T , L s , e) where transition 
(1) is produced by actj and transition (2) by act 2 . Since transitions (1) and (2) are not conflicting, then 
both sequences (1) then (2) and (2) then (1) are possible and reach the same state. □ 



J. Michaux, E. Najm & A. Fantechi 



69 



Property 4. 

(i) All sink states of r-cg(act) (i.e. states with no outgoing transitions) are of the form (c, nil). (Hence 
sink states may differ only by their control link maps), 

( ii) for any state ofr-cg( act), there exists a path that leads to a sink state. 

Proof. ( sketch ) 

(i) Let us consider the non trivial case where act is not an atomic activity, and a state (c, acto) reachable 
from the initial state (c act ,act). If acto-BEH = nil then (c, acto) cannot be a sink state since it can make 
a transition to (c, nil). If acto-BEH ^ nil then surely there is one activity act' G acto-BEH which is head 
and ready for execution in the context of control link map c. This stems from the non cyclicity property 
which, it can be proven, is preserved along the execution path from the initial state. This means that all 
the activities in act that preceed act' have been either executed or cancelled. Hence, (c, acto) can make 
a transition (the one derived from act'), and thus cannot be a sink state. 

(ii) the inspection of all sos rules shows that for all states (c,acto), where acto is not a repeat activity, 
there is a transition to some other state (c', act') where act' is strictly (syntactically) simpler (i.e., smaller 
in size) that acto. In the case of repeat, there is also always a path leading to a syntactically simpler 
activity, which is through the pre-empting activity pic 2 . nil being the simplest activity, thus all activities 
must reduce to nil. 

□ 

4.4 Control Graph Transformations 

The first transformation applied to r-cg(act) is T-prioritization and results in control graph Tp-cg(act). 
Then we apply T-compression, resulting in control graph TC-cg(act) that is free of z transitions. Next 
comes a transformation into run-to-completion semantics resulting in rtc-cg(act). Finally, strong equiv- 
alence minimization is applied resulting in cg(act), a graph with a single sink state. 

4.4.1 T-Priorisation and T-Compression 

In flU, the authors give an efficient algorithm that, given a graph in which the z transitions are confluent 
and in which there are no z loops, prioritises z transitions in the graph while preserving branching 
equivalence. Given Property [3] i.e that the z transitions of any r-cg(act) are confluent, and Property [2] 
i.e there are no z loops in any r-cg(act), we can apply the algorithm given in [8] and obtain a T-prioritised 
control graph that we call Tp-cg(act). In such a graph, the outgoing transitions from a state are either 
all z transitions, or they are all observable actions. In [8], an algorithm for T-compression is also given, 
essentially leaving the graph z transition free. We can therefore apply T-compression to Tp-cg(act) and 
obtain a T-free branching equivalent control graph that we call Tc-cg(act). 

4.4.2 Applying run-to-completion semantics 

Here we process control graphs so as to verify the run-to-completion property. This property implies the 
following behavior of control graphs: after a receive, all possible invocations, session initiations, or z 
actions are executed before another message can be received. 

In order to give SeB a run-to-completion semantics, we give a priority order to the transitions in a 
T-prioritised control graph Tp-cg(act) (this also applies for T-compressed control graphs). We consider 
the outgoing transitions from a state and we define the following priority order between the actions that 
label these transitions: s!op(x) > s@p > s?op(x). This means that when two transitions labelled with 
actions with different priorities are possible from a given state, then the one having a lower priority is 
pruned. All states that have become unreachable from the initial state are also pruned. 
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Figure 2 shows the control graph generated for the QuoteComparer SeB service shown in |Figure 1 



in which the T-priorisation and run-to-completion semantics transformations have been applied. X- 
compression was not applied here for the sake of illustration. In this figure, the computation between 
states and 17 represents an example of run-to-completion. 



Note that the control graph of |Figure 2] contains 5 terminal states. They all correspond to couples 
of the form (c,-, nil), in accordance with Property 4. They differ only by their control link maps. For 
example, state 48 corresponds to the couple (C48, nil) where C48 is given by c^(h) = c^%{l-j) = c^{U) = 
£48(^5) = true and where is false for the remaining links. 

4.4.3 Minimisation 



When strong (or branching) equivalence minimisation is applied to control graph rtc-cg(act), a minimal 
control graph cg(act) is produced that has one and only sink state (because all sink states are equivalent). 
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Figure 3: The QuoteComparer Reduced Control Graph 



Figure 3| shows the minimised control graph of the QuoteComparer example. We used the CADP Q 
toolset to perform some of the transformations defined in this section on the QuoteComparer example. 

4.5 Semantics of activities 

Henceforth, when we write cg(act) for any well-formed activity act, we will consider that we are dealing 
with the T-compressed, run-to-completion and minimised control graph, and we name its unique sink 
state term(act), to be referred to as the terminal state. We also adopt the following notations: init(act) 
denotes the initial state of cg(act); states(act) is the set of states of cg(act); trans(act) is the set of 
transitions of cg(act). A transition in this final control graph cg(act) will be denoted by g —> g'. 

Definition 4.7. Open for reception - A state g ofcg(act) is said to be open for reception on session s and 
we note open(act,g,s), iff state g has at least one outgoing transition labeled with a receive action on 

session s. More formally: open(act,g,s) =def 3 op, X\ . . . x ni g f such that g ■ — — H> g f . 

3 ' act 

4.6 Free, bound, usage and forbidden occurrences of variables 

Definition 4.8. Variables of an activity - For an activity act we define the set of variables occurring in 
act: V(act) = def {z \ z occurs in act}. 

Definition 4.9. Binding occurrences - For variables y £ V(act), s € V(act) and p G V(act), the fol- 
lowing underlined occurrences are said to be binding occurrences in act: s@p, slop{- ■ ■ ,y,---) and 
slop{- ■ ■ ,p, ■ ■ ■ ). We denote BV(act) the set of variables having a binding occurrence in act. 
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Definition 4.10. Usage occurrences - For variables y G V(act), s G V(act) and p G V(act), the fol- 
lowing underlined occurrences are said to be usage occurrences in act: s@p, slop(---), s\op(---), 
s\op{- ■■ ,p, • • • ) and s\op{- ■ ■ ,y,- ■ ■ ). We denote UV(act) the set of variables having at least one usage 
occurrence in act. 

Definition 4.11. Free occurrences - A variable z G V(act) is said to occur free in act, iff there is a 
path in cg(act): init(act) g\, ■ ■ ■ ,g n -\ g n where z has a usage occurrence in o n and has no 

binding occurrence in any of <J\,- - , <J n -i- We denote FV(act) the set of variables having at least one 
free occurrence in act. 

Definition 4.12. Forbidden occurrences - opl(- • -po • • • ) and sq@p are forbidden occurrences. As we 
shall explain later, po is reserved for the own location of the service, while sq is a reserved session 
variable that receives a session id implicitly at service instantiation time. 

5 Syntax and Semantics of Service Configurations 

SeB activities can become deployable services that can be part of configurations of services. These 
configurations have a dynamic semantics, based on which we can define the property of safe interaction. 

Let M be a partial map from variables Var to Vol U {_L}, the set of values augmented with the 
undefined value. Henceforth, we consider couples (M, act) where dom(M) = V(act). 

5.1 Deployable Services 

Definition 5.1. Deployable services - The couple ((M, pic)) is a deployable service iff: 
• po G FV(pic), sq G FV(pic) • FV(pic) D SesVar = {sq} • p/c.BEH = J^so^opi(xi);acti 

. dom(M) = V(pic) . Vz G V(pic) \ FV(pic) : M(z) =± • VzG FV(pic) \ {s } : m{z) ^± 

Informally, (M, act) is a deployable service if act is a pic, sq is its only free session variable, 
the initial receptions of pic are on session so, its location is defined (variable po is set in M), 
and all its free variables, except sq, have defined values in M. 

Definition 5.2. Running service instances - The running state of a service instance derived from the 
deployable service ((M, pic)) is the triple (m, pic+g) where: g G states (p/'c) and dom(m) = dom(M). 
The initial state of this running service instance is the triple (M[% ], p/c*init(p/c)) with j3 fresh. A 
deployed service behaves like a factory creating a new running service instance each time it receives a 
session initiation request. 

5.2 Service Configurations 

Configurations are built from deployable services. We provide an abstraction of the communication 
bus that is necessary to formalize and prove the desirable properties of service configurations. Service 
instances exchange messages through FIFO queues, and session bindings are set up in order to establish 
the corresponding queues. 

Definition 5.3. Service configurations - When deployed, a set of deployable services yields a configu- 
ration noted: ((Mijp/q)) o ••• o ((M^jp/c^)). The symbol o denotes the associative and commutative 
deployment operator, meaning that services are deployed together and share the same address space. 
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Definition 5.4. Well-partnered service configuration - A service configuration ((M^p/q)) o ■■■ o ([M k ,pic k ]) 
is said to be well partnered iff: 
. Vi, y.i + i^ Mi(po) / My(p ) • Vi.p : M,-(» /_L^ 3j with M t {p) = Mj(p ) 

That is, any two services have different location addresses, and any partner required by one 
service is present in the set of services. 

5.3 Running Configurations 

Definition 5.5. Message queues - is a set made of message queues with ::= q \ qo £}, where q is 
an individual FIFO message queue of the form q ::= 8 Mes with Mes a possibly empty list of ordered 
messages and 8 the destination of the messages in the queue. The contents of Mes depend on the kind 
of the destination 8. If 8 is a service location, Mes contains only session initiation requests of the form 
new(oc). However if 8 is a session id, then Mes contains only operation messages of the form op(w). 
Definition 5.6. Session bindings - A session binding is an unordered pair of session ids (oc, j6). A running 
set of session bindings is noted SS and has the syntax SB ::= ((X, j3) | (ot, jS ) o SS. If (<X,j3) £ then 
a and j3 are said to be bound and messages sent on local session id (X are routed to a partner holding 
local session id j3, and vice-versa. 

Definition 5.7. Running configurations - A running configuration, C, is a configuration made of services, 
service instances, queues and bindings all running concurrently and sharing the same address space: 
^ = ^servO^i, act\,gi) - (mk, actfagkjoJSo^S where ^ er v = ((^liP'^i)) ■ ■ • $M„, pic n ]) is a well-partnered 
service configuration, and (m[,acti,gi)-(m k ,act k ,g k ) o,re service instances. 

Again, operator o is associative and commutative hence the order of services, instances, bindings and 
queues is irrelevant. Also if the sets of bindings or queues are empty, they are omitted. 
Definition 5.8. Initial Running configuration - A service configuration cannot bootstrap itself as this 
requires at least one client instance that begins by opening a session, (m, act,g) is one such client where 
act. beh = s@ p; act! and 3/ such that m(p) = Mj(po). Hence the minimal initial running configuration 
is: C = {Mi , p/q )) • • • (M„ , p/cj) o (m, act, g) . 



5.4 Semantics of Service Configurations 

Here we provide a full semantics for SeB that allows us to formalize the property that we want to assess 



in SeB programs. The service configuration semantics is defined using the four sos rules in |Table 5| 

SES1 applies when a service instance has a session initiation transition, s@p, where m{p) is the 
address of the remote service. The result is that the two fresh session ids a and j3 are created for the 
local and distant session ends, and message new(fi) is added to the tail of the message queue targeting 
service %. SES2 applies when message new(fi) is at the head of the input queue of the service located 
at K (for which m(po) = n). The result is that the message is consumed and a new service instance is 
created with root session sq set to j8 . INV states that when a service instance is ready to send an invocation 
message over session s, then the message is appended to the queue whose target is j3 which is bound to 
m(s). REC is symmetrical to INV. 



5.5 Interaction-safe Service Configurations 

The property of interaction safety is verified when no service instance ever reaches a state in which it is 
awaiting a message, but the message at the head of the corresponding input queue is not expected. The 
definition that follows is given in two parts, the second depends on the first. 
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g s p > g' a, ft fresh 



- (ra,act + g) ■■■ o ■■■ (m(p) 4-^ Mes) ■■■ o 2$ — > 
(m[ a / s ], act *-g') - o -(m(p) ^ Mes-new(P) ) •■■ o3$o (ot,/J) 



M(p ) = K 



((M, pic)) ■■■ © ■■• (n 4-^ new(p)-Mes) ■■■ o — > 
■ ((M, pic)) o (M[P/ So \, pic »-init(pic) ) ••• o ••• (7T^m5) ■■■ 

S 8 sU ' plx ^ x " ] > g> (m{s),P)ea 
••■ (m, act ►•#) ■•• o ••■ i/j Ms) -- o — > 

■•• (m, act ••• O ••• ( j3 Mes-op(m(x { ),-■-, m(x„)) ) ••• o£ 



8 : >8 m(s)=p 



■ (m,act *-g) ■■■ o ■■■ (P op(wi,-, w n )-Mes) ■■■ o 
... ..,"%,], act >f?) ■■■»■■■ {p^ Mes)- om 

Table 5: sos Rules for Service Configurations 



Definition 5.9. One-step Interaction-safe Running Configurations - A running configuration 

<€= ((Mi,p/c 1 ))---((M„,p/c„))o(/ni,acti >g x \ ■ -(m k ,act k +g k )o£o38 
is one-step interaction-safe iff for any (service or client) instance j, any session variable s, and any 
operation op the following implication holds: 

nij(s) op(wi,...,wi) • Mes € J£ (for some values w\, ... ,wi), and open(actj,g j,s) 

s r >op(x' l ,...jc'i) 

=^ gj ■ — y (for some variables x l , . . . ,X{) 



Definition 5.10. Interaction-safe Service Configuration - A service configuration C sen , is interaction-safe 
iff for any client instance (m, act,g) and any running configuration C reachable from C serv o (m, act,g), 
C is one-step interaction-safe. 

6 Related work 

The potential of sessions in programming languages has gained recognition recently, and languages such 
as Java ifTTll and Erlang [16] have been extended in order to support them. In the service orchestration 
community, a significant body of work looks at formal models that support sessions for services as a 
first-class element of the language, such as in the Service-Centered Calculus (SCC) HI, CaSPiS JH, and 
Orcharts 0, among others. To the best of our knowledge, our work on SeB is the first that has introduced 
sessions into the widely adopted bpel |[T8l orchestration language. 

Other formalizations of bpel have been suggested. For instance, in HI] the authors defined an al- 
gorithm to derive data-links from bpel code by evaluating the control flow of processes as described by 
their control links. In our work, we have taken a step further and given an overall static semantics of 
variables in bpel, which has allowed us to define the notion of a well structured activity, bpel models 
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are quite often based on Petri nets |[T9l[T5ll , which lend themselves well to the task of formalizing con- 
trol links. By separating our semantics into two steps, we were able to propose a formal specification 
of bpel with control links more concisely than with Petri nets, notably when it comes to capturing the 
behavior of dead-path elimination. Other work suggests a formalization that takes into account typing of 
bpel process with wsdl descriptors lPT3l . The session types defined in the present paper can model wsdl 
descriptors, and they add the possibility to model a service's behavior. 

bpel |[T8l uses correlation sets rather than sessions to relate messages belonging to a particular in- 
stance of an interaction. Messages that are logically related are identified as sharing the same correlation 
data [12]. We could have defined a "session oriented" style for bpel implemented with correlation sets, 
but this approach would not lend itself easily to behavioural typing which is our objective for SeB. While 
bpel correlation sets allow for multi-party choreographies to be defined, we argue that similar expressiv- 
ity is attainable with session types by extending them to support multi-party sessions. This challenge for 
future work has been addressed outside the context of bpel in (9J, [3]| . In [20] a calculus based on process 
algebra and enhanced with a system for correlating related operations is presented. This calculus was 
shown to be able to reach a certain degree of BPEL-like expressiveness. 

Blite [ 14] is a formalized subset of bpel with operational semantics that take into account correlation 
sets. The authors have also written an associated translator that converts Blite code into executable bpel. 
Blite uses a wsDL-typing system, but it does not feature control links. 

7 Conclusion 

In order to provide a basis for formal reasoning and verification of service orchestrations, we have 
adapted and formalized a subset of the widely adopted orchestration language bpel. The resulting for- 
malism, that we call SeB for Sessionized bpel, supports sessions as first class citizens of the language. 
The separation of the proposed operational semantics into two steps has allowed a relatively concise 
semantics to be provided when compared to previous approaches. Furthermore our semantics take into 
account the effect of bpel control links, which are an essential and often neglected part of the language. 

In the sequel, we plan to use session types as a means of prescribing the correct structure of an 
interaction between two partner services during the fulfillment of a service. A typed SeB service will 
declare the session types that it can provide to prospective partners, while also declaring its required 
session types. A verification step will be needed to see whether or not a service is well-typed, hence 
answering the question of whether or not the service respects its required and provided types. 

We will also investigate and show how the interaction safety property, that we defined on the basis 
of the semantics of SeB, can be guaranteed in configurations of compatible and well typed services. The 
formal approach taken with SeB as presented in this paper also opens up the possibility of defining and 
proving other properties of Web service interactions, such as controllability and progress properties. The 
study of all these verification aspects is left to future work. 
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